Ansible2.3 から Ansible 2.4
サポートするPythonのバージョン
Anabilities 2.4 からターゲットホスト上のPython 2.4または2.5はサポートされません。
このバージョン以降、ターゲットホスト上では、Python 2.6以上が必要になります。
インベントリ
インベントリはプラグインを介して実装されるように書き直されて、複数のソースが可能になりました。
この変更は、ほとんどの場合ユーザーは意識する必要はありません。
1つの例外は inventory_dir で、これはホスト変数になりました。これまでは1つの値しか持たないため、グローバルに設定されていました。 この変更はプレイブックの早い段階でホストを特定するために inventory_dir が使えなくなりました。
add_hosts と暗黙的な localhost の動作も変更されています。グローバル変数を自動的に継承しないため、デフォルトでは None になります。
inventory_file はほとんど変更されていないため、これまで通り常にホストごとの設定を行います。
単一のインベントリは存在しなくなっているので、暗黙的な localhost は、これらの変数のいずれも定義しません。
inventory path/directory のバグが修正されました。デフォルトでカレントディレクトリとなります。
この修正により、ホストリスト(コンマで区切られたホスト名)がインベントリとして与えられたときに、
プレイブックまたはインベントリディレクトリのすぐ隣でなく、
カレントディレクトリから group_vars および host_vars を参照できるようになります。
最初のプレイブックとそれに関係する group_varsとhost_vars
Ansible 2.4より前のバージョンでのインベントリシステムは実行された最初のプレイブックのコンテキストを維持します。
これにより、他のディレクトリのプレイブックを連続して含むことができ、トップレベルのプレイブックファイルに関連して配置された group_vars と host_vars を継承することができました。
いくつか動作の不一致があったことにより、この機能は Ansible 2.4以降の新しいインベントリシステムから削除されています。
インベントリファイルに対して相対的に配置された vars_files、include_vars、またはgroup_varsおよびhost_varsを使用することによって同様の機能を実現できます。
廃止予定
インベントリ・ソースの指定
コマンド行で --inventory-file を使用することは推奨されなくなりました。--inventory または -i を使用します。
関連する ansible.cfg での hostfile、および環境変数 ANSIBLE_HOSTS も廃止予定です。
ansible.cfg では inventory および、環境変数 ANSIBLE_INVENTORY に置き換えられます。
複数のタグの使用
コマンドラインで--tags(または--skip-tags)を複数回指定すると、現在のコマンドラインの最後のものがすべて上書きされます。 この動作は推奨されなくなりました。
将来、タグを複数回指定すると、タグは一緒にマージされるようになります。
Ansible 2.4 以降では、1つのコマンド行で --tags を複数回使用すると廃止予定の警告が表示されます。
Ansible 2.4では、デフォルトではタグをマージするように変更されています。
古い上書き動作を有効にするには ansible.cfgファイルで merge_multiple_cli_tags オプションを False に設定します。
Ansible 2.5では、複数の--tagsオプションはマージされ、(タグが上書きする)古い動作は廃止されます。
モジュール
このバージョンから、win_shellとwin_commandモジュールは、コマンドラインで引用符で囲まれた引数を適切に保持するようになりました。
余分な引用符/エスケープを追加して問題を回避しようとしていたタスクは、余計なエスケープを削除する必要があります。
廃止されるモジュール
このバージョンで廃止されるモジュールはありません。
非推奨
以下のモジュールはAnsible 2.8で削除される予定です。
azure
azure_rm_virtualmachine を使用します。これは、新しいResource Manager SDKを使用します。
win_msi
代わりにwin_packageを使用します。
プラグイン
プラグインの設定とドキュメント作成の新しい方法が紹介されました。
これは既存の設定を変更する必要はありませんが、開発者は新しいインフラストラクチャに順応するようになります。
varsプラグインの変更
varsプラグインの実装には多くの変更がされましたが、ユーザーと開発者のいずれも、既存のプレイブックやタスクを変更する必要はありません。 新規に開発するときでは、開発者はプラグインの変更を検討して新しい機能を利用する方がよいでしょう。
大きな違いはvarsプラグインがインベントリ作成時ではなくオンデマンドで呼び出されるようになったことです。
これにより、特にホストのサブセットを使用している場合に、大規模なインベントリに対してより効率的になるはずです。
プレイブックの動作をきめるためのgroup/host_vars を使うようなことがありましたが、これら挙動も変更されています。
これまでのバージョンでは、「最初の」プレイブックが変数をロードしていました。現在は、「今の」プレイブックが変数をロードするようになっています。パスにある全てのプレイブックは変数をロードする必要があるからです。
Ansible 2.4.1 でこの制御を行えるトグルが追加されました。top は Ansible 2.4 以前の動作となり、bottom は現在のプレイブックで保持されているタスクとなり、all はtopとbottomの両方の動作となります。
インベントリプラグイン
開発者は、ハードコードされたインベントリから動的インベントリスクリプトを使用した新しいインベントリプラグインに移行する必要があります。 スクリプトインベントリプラグインを使用してもスクリプトは引き続き動作しますが、
Ansibleの開発は現時点でスクリプトを強化するのではなく、プラグインの開発に集中しています。
動的インベントリスクリプトで見つかった多くのハックと回避策の必要性を軽減するため、ユーザと開発者は新しいプラグインを検討する必要があります。
コールバックプラグイン
ユーザ
コールバックは新しい設定システムを使用していて、 古いシステムもそのまま動作するので、ユーザは何も変更する必要はありませんが、使用されているコールバックが組み込みのクラスから継承していない場合は非推奨通知が表示されることがあります。
開発者
あなたのコールバックがCallbackBase(直接または間接的に別のコールバック呼ばれた)から継承されていない場合でも機能しますが、廃止予定の通知が発行されます。これを回避し、将来的にはCallbackBaseから継承するように変更するための、メソッドやプロパティを扱う新しいオプションが追加されています。 メソッドとプロパティを扱う新しいオプションを実装することもできますが、将来追加される変更は自動的に継承されません。
他のコールバックを継承するコールバックも、親と同じ定義のオプションを含むように更新する必要があるか、オプションを使用できない可能性があります。
テンプレートルックアッププラグイン:エスケープ文字列
Anipal 2.4以前では、テンプレートルックアッププラグインに渡された文字列のバックスラッシュは自動的にエスケープされます。
Ansible 2.4からユーザーはバックスラッシュ自体をエスケープする必要があります。 この変更により、テンプレートルックアッププラグインがテンプレートモジュールでインライン化され、同じバックスラッシュエスケープルールが両方に適用されます。
次のようなコードがあるとき、
code: ansible
- debug:
msg: '{{ lookup("template", "template.j2") }}'
Ansible 2.4 以前ではこう記述できました。
code: ansible
{{ "name surname" | regex_replace("^^\s+\s+(.*)", "\1") }} Ansible 2.4 以降では次のようにバックスラッシュをエスケープする必要があります。
code: ansible
{{ "name surname" | regex_replace("^^\\s+\\s+(.*)", "\\1") }} テスト
テストのsucceeded/failed
Ansible 2.4以前では、タスクの戻りコード rc は戻りコード failed を上書きしていました。
Ansibke2.4からは、rc とfailed の両方を使用してタスクの状態が求められるようになりました。
このため、テストプラグインのsucceeded/failed も変更されています。
これは、タスク失敗をfailed_whenで上書きすると、succeeded/failed がTrue / Falseを返すことになります。
例:
code: ansible
- command: /bin/false
register: result
failed_when: no
- debug:
msg: 'This is printed on 2.3'
when: result|failed
- debug:
msg: 'This is printed on 2.4'
when: result|succeeded
- debug:
msg: 'This is always printed'
when: result.rc != 0
この例からわかるように、Ansible 2.3ではsucceeded/failedはrc の値だけをチェックしていました。
ネットワーキング
ネットワークモジュールの動作方法にはいくつかの変更があります。
Playbookは引き続き connection:local を使用する必要があります。
永続的な接続
Ansible 2.3で追加された設定変数 connection_retries と connect_interval は廃止予定です。
Ansible 2.4以降では、connection_retry_timeout を使用するようにしてください。
タイムアウトを制御するには、[default] の前のトップレベルの timeout ではなく、command_timeout を使用します。
コンフィギュレーション
コンフィギュレーションシステムには大きな変更がありましたが、 次の場合を除き、ユーザーは影響を受けないはずです。
定義されたすべての相対パスは、anipal.cfg ファイル自身に影響します。
以前は、設定によってさまざまでしたが、新しい挙動ではより予測しやすくする必要があります。
新しいマクロ {{CWD}} をパスに使用できます。パスは現在の作業ディレクトリに相対的で表現されますが、
これは安全ではありませんが、実際にこの動作に依存したいユーザーもいます。
以前のAPIで直接作業していた開発者は、下位互換性を保つためにいくつかのメソッド(たとえばget_config)が保持されていたため、その使用方法を確認する必要があるかもしれません。